Architecture Governance

ISO/IC 38500:2015 defines governance as: "a system that directs and controls the current and future state". The process by which direction and control is provided should take into account equality of concern and transparency, protecting the rights and interests of the business.

Governance is a decision-making process with a defined structure of relationships to direct and control the enterprise to achieve stated goals. The key difference between governance and management rests on the cornerstone of fiduciary and sustainable responsibility. To define a customised governance approach, let us start to define the following:

1. What is to be governed?
2. Why should something be governed?
3. When and who should decide on the recommended alternatives?
4. How does this link to the EA process ?

Common mistakes to avoid are “fixing the blame” and “warned you before” processes and allowing weak policies that are focused on narrow-minded interests instead of securing the interests of the enterprise.

Levels of Governance within the Enterprise

Architecture Governance is the practice and orientation by which Enterprise Architectures and other architectures are managed and controlled at an enterprise-wide level.

Architecture Governance typically does not operate in isolation, but within a hierarchy of governance structures, which, particularly in the larger enterprise, can include all of the following as distinct domains with their own disciplines and processes:

• Corporate Governance
• Technology Governance
• IT Governance
• Architecture Governance

Each of these domains of governance may exist at multiple geographic levels - global, regional, and local – within the overall enterprise.

Corporate governance is thus a broad topic, beyond the scope of an Enterprise Architecture framework such as the TOGAF framework.

This and related subsections are focused on Architecture Governance; but they describe it in the context of enterprise-wide governance, because of the hierarchy of governance structures within which it typically operates, as explained above.

Nature of Governance

Governance: A Generic Perspective

Governance is essentially about ensuring that business is conducted properly. It is less about overt control and strict adherence to rules, and more about guidance and effective and equitable usage of resources to ensure sustainability of an organisation's strategic objectives.

The following outlines the basic principles of corporate governance, as identified by the Organisation for Economic Co-operation and Development (OECD):

• Focuses on the rights, roles, and equitable treatment of shareholders
• Disclosure and transparency and the responsibilities of the board
• Ensures:
  • Sound strategic guidance of the organisation
  • Effective monitoring of management by the board
  • Board accountability for the company and to the shareholders
• Responsibilities of the Board:
  • Reviewing and guiding corporate strategy
  • Setting and monitoring achievement of management's performance objectives

Supporting this, the OECD considers a traditional view of governance as: "... the system by which business corporations are directed and controlled. The corporate governance structure specifies the distribution of rights and responsibilities among different participants in the corporation - such as the board, managers, shareholders, and other stakeholders - and spells out the rules and procedures for making decisions on corporate affairs. By doing this, it also provides the structure through which the company objectives are set, and the means of attaining those objectives and monitoring performance" (Source: OECD, 2001).

Characteristics of Governance

The following characteristics have been adapted from Corporate Governance (Naidoo, 2002) and are positioned here to highlight both the value and necessity for governance as an approach to be adopted within organisations and their dealings with all involved parties:

Discipline
All involved parties will have a commitment to adhere to procedures, processes, and authority structures established by the organisation.

Transparency
All actions implemented and their decision support will be available for inspection by authorised organisation and provider parties.

Independence
All processes, decision-making, and mechanisms used will be established so as to minimise or avoid potential conflicts of interest.

Accountability
Identifiable groups within the organisation - e.g., governance boards who take actions or make decisions - are authorised and accountable for their actions.

Responsibility
Each contracted party is required to act responsibly to the organisation and its stakeholders.

Fairness
All decisions taken, processes used, and their implementation will not be allowed to create unfair advantage to any one particular party.

Governance is about a hierarchy of decision-making that everyone commits to. Governance can be used to drive a set of behaviours. The act of observation by the governance team should not change the fact or how something is done. An observation results in some form of measurement.
Define a set of measurements and metrics that can be used to achieve organisational objectives.
Being transparent about why the measurement is being made and what mitigation options are available will drive positive behaviour. Revisit the previous chapter to fine tune what to measure and why that measurement is needed.

Identify and define appropriate governance tiers to align what, how, when, and which tier gets escalated for relief. Absence of relief within each tier will result in loss of effective control and local autonomy. In general, lower tiers tend to be tactical in scope. Cross-cutting or higher tiers constrain lower tiers.

It is likely that the enterprise already has processes defined for some or all of the tiers shown in Figure 8.

Essential Governance

A common failure pattern is to establish an EA governance board that believes it maintains decision rights about the target architecture, change to the architecture, relief, and enforcement.

Decision rights about the target architecture, relief, and enforcement are always vested in the architecture's stakeholders. Successful teams providing the EA Capability make sure that even within the lowest tier (technology architecture governance), stakeholders own the decision rights. An EA governance board owns process, and a recommendation regarding completeness and confidence in the work that led to the target architecture.

The short decision-tree checklist for an EA board to require an architect to answer when assessing a target architecture is given below. Note that it may sound natural to start anywhere on this checklist or pursue answers to these questions simultaneously. Experience has shown this approach to create more work than making governance invisible; however, it has proved to be effective. Notice the choice of words at the beginning of the paragraph.
All questions are mandatory. As in any decision-tree, a negative response may force you to re-enter the tree at a higher level.

| | | | | --- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | Were the correct stakeholders identified? | Yes/No
 If yes, proceed
 If no, direct the architect to engage with the stakeholders appropriate to the scope of the architecture being developed. | | 2 | Were constraints and guidance from the superior architecture taken into account? | Yes/No
 If yes, proceed
 If no, direct the Practitioner to perform their job and take into account guidance and constraints from the superior architecture. Where the Practitioner identifies a conflict, obtain a recommendation on whether to grant relief from the superior architecture or enforce the superior architecture. This decision must be made by the superior architecture stakeholders. | | 3 | Do appropriate SMEs agree with the facts and interpretation of the facts in the architecture? | Yes/No
 If yes, proceed
 If no, the Practitioner has to do their job and engage with the SMEs. Where the Practitioner identifies a conflict with, or between, SMEs, develop a recommendation for the stakeholders that they should have limitations in confidence. | | 4 | Do any constraints or guidance produced reflect the views produced for stakeholders and any underpinning architecture models and analysis? | Yes/No
 If yes, proceed
 If no, the Practitioner needs to do their job and develop appropriate views that are consistent with analysis. | | 5 | Do the views produced for the stakeholders reflect their concerns and reflect any underpinning architecture models and analysis? | Yes/No
 If yes, proceed
 If no, the Practitioner needs to do their job and develop appropriate views. | | 6 | Do the stakeholders understand the value, and any uncertainty in achieving the value, provided by reaching the target state? | Yes/No
 If yes, proceed
 If no, the Practitioner needs to do their job and develop appropriate views, and other work products, then return to the stakeholders. | | 7 | Do the stakeholders understand the work necessary to reach the target state and any uncertainty (risk) in successfully accomplishing the work? | Yes/No
 If yes, proceed
 If no, the Practitioner needs to do their job and develop appropriate work products and return to the stakeholders. | | 8 | Do the stakeholders understand any limitations in confidence they should have in the Target Architecture? | Yes/No
 If yes, proceed
 If no, the Practitioner needs to do their job and develop appropriate guidance on the limitations in confidence and return to the stakeholders. | | 9 | Have the stakeholders approved the views? | Yes/No |

If the answer to the last question is yes, the EA board should approve the architecture for publication in the EA repository as the approved target architecture. Because the failure pattern is so embedded in practice we will re-iterate: there is no role for the EA governance board to debate, or approve, the contents of the target architecture and its constraints or guidance.

If the answer to the last question is no, the EA board should make a decision to either direct the architect to re-work the architecture usually through more advanced trade-off, or more often embracing the stakeholders' preferences, or cancel the architecture initiative.

When the architecture is being used, changes to the enterprise are being guided, or constrained.

Two factors impact governance of change. First, organisations operate in a dynamic environment, and the analysis of the target architecture cannot have assessed every circumstance or change option possible. Second, the target was produced for a purpose and may not have been developed to the level of detail required for the current use. The governance process requires the ability to change the architecture, provide relief from constraint, and enforce the architecture.

The role of EA governance is to manage the process of assessing compliance. All change is subject to compliance reviews against the constraints and guidance in the target architecture.

Typically, these assessments are performed on a periodic basis to assess the operationally changing current state, and associated with a project to assess project-driven change. Where there is non-compliance, the stakeholders have three choices: first, enforce compliance; second, provide relief; and third, change the target architecture.

1	Did the organisation embarking on a change reasonably interpret the target architecture’s guidance and constraints?	Yes/No  If yes, their interpretation should be accepted as compliance and any issues addressed through a change to the architecture  If no, proceed
2	Do appropriate subject matter experts agree with the facts and interpretation of the facts in the impact assessment?	Yes/No  If yes, proceed  If no, either direct the architect to engage with the subject matter experts or develop a recommendation for the stakeholders that they should have limitations in confidence
3	Do appropriate subject matter experts agree with the recommendation to enforce the target, grant time-bound relief, or change the architecture?	Yes/No  If yes, proceed  If no, either direct the architect to engage with the subject matter experts or develop a recommendation for the stakeholders that they should have limitations in confidence
4	Do the views produced for the stakeholders reflect the impact assessment and reflect any underpinning architecture models and analysis?	Yes/No  If yes, proceed to the stakeholders for approval  If no, direct the architect to develop appropriate views
5	Do the stakeholders understand any limitations in confidence they should have in the impact assessment?	Yes/No  If yes, proceed  If no, direct the architect to develop appropriate views and return to the stakeholders
6	Do the stakeholders understand the impact on prior expected value, and any change in certainty in achieving the value, provided by reaching the target state?	Yes/No  If yes, proceed  If no, direct the architect to develop appropriate views and return to the stakeholders
7	Have the stakeholders approved the recommendation to enforce the target, grant relief, or change the architecture?	Yes/No

If the answer to the last questions is yes, the EA board should approve the non-compliance action recommendation for publication in the EA repository. Because the failure pattern is so embedded in practice, we will re-iterate: there is no role for the EA governance board to debate, or approve, the recommendation. Lastly, where relief is provided, the EA board should ensure that future compliance assessment and reporting take place to review time-bound relief. Without this step the enterprise has simply agreed to change the target architecture without the bother of an approval.

If the answer is no, the EA governance board has a difficult decision. In short, either the architect must be directed to expand the information provided to the stakeholders, or re-work the recommendation to embrace the stakeholders preferences.

Design of the EA governance two essential practices must be done in the context of the enterprise's existing governance, reporting, and ERM practices.

Architecture Board

Role

A key element in a successful Architecture Governance strategy is a cross-organisation Architecture Board to oversee the implementation of the strategy. This body should be representative of all the key stakeholders in the architecture, and will typically comprise a group of executives responsible for the review and maintenance of the overall architecture.

Architecture Boards may have global, regional, or business line scope. Particularly in larger enterprises, Architecture Boards typically comprise representatives from the organisation at a minimum of two levels:

• Local (domain experts, line responsibility)
• Global (organisation-wide responsibility)

In such cases, each board will be established with identifiable and articulated:

• Responsibilities and decision-making capabilities
• Remit and authority limits

Responsibilities

The Architecture Board is typically made responsible, and accountable, for achieving some or all of the following goals:

• Providing the basis for all decision-making with regard to the architectures
• Consistency between sub-architectures
• Establishing targets for re-use of components
• Flexibility of the Enterprise Architecture:
  • To meet changing business needs
  • To leverage new technologies
• Enforcement of Architecture Compliance
• Improving the maturity level of architecture discipline within the organisation
• Ensuring that the discipline of architecture-based development is adopted
• Supporting a visible escalation capability for out-of-bounds decisions

Further responsibilities from an operational perspective should include:

• All aspects of monitoring and control of the Architecture Contract
• Meeting on a regular basis
• Ensuring the effective and consistent management and implementation of the architectures
• Resolving ambiguities, issues, or conflicts that have been escalated
• Providing advice, guidance, and information
• Ensuring compliance with the architectures, and granting dispensations that are in keeping with the technology strategy and objectives
• Considering policy (schedule, SLAs, etc.) changes where similar dispensations are requested and granted; e.g., new form of service requirement
• Ensuring that all information relevant to the implementation of the Architecture Contract is published under controlled conditions and made available to authorised parties
• Validation of reported service levels, cost savings, etc.

From a governance perspective, the Architecture Board is also responsible for:

• The production of usable governance material and activities
• Providing a mechanism for the formal acceptance and approval of architecture through consensus and authorised publication
• Providing a fundamental control mechanism for ensuring the effective implementation of the architecture
• Establishing and maintaining the link between the implementation of the architecture, the architectural strategy and objectives embodied in the Enterprise Architecture, and the strategic objectives of the business
• Identifying divergence from the architecture and planning activities for realignment through dispensations or policy updates

Architecture Contracts

Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture.
Successful implementation of these agreements will be delivered through effective Architecture Governance.

By implementing a governed approach to the management of contracts, the following will be ensured:

• A system of continuous monitoring to check integrity, changes, decision-making, and audit of all architecture-related activities within the organisation
• Adherence to the principles, standards, and requirements of the existing or developing architectures
• Identification of risks in all aspects of the development and implementation of the architecture(s) covering the internal development against accepted standards, policies, technologies, and products as well as the operational aspects of the architectures such that the organisation can continue its business within a resilient environment
• A set of processes and practices that ensure accountability, responsibility, and discipline with regard to the development and usage of all architectural artefacts
  A formal understanding of the governance organisation responsible for the contract, their level of authority, and scope of the architecture under the governance of this body

The traditional Architecture Contract is an agreement between the sponsor and the architecture function or Information Systems (IS) department. However, increasingly more services are being provided by systems integrators, applications providers, and service providers, co-ordinated through the architecture function or IS department. There is therefore a need for an Architecture Contract to establish joint agreements between all parties involved in the architecture development and delivery.

Architecture Contracts may occur at various stages of the ADM; for example:

• The Statement of Architecture Work created in Phase A of the TOGAF Standard
• Architecture Development Method is effectively an Architecture Contract between the architecting organisation and the sponsor of the Enterprise Architecture (or the IT governance function)
• The development of one or more architecture domains (Business, Data, Application, Technology), and in some cases the oversight of the overall Enterprise Architecture, may be contracted out to systems integrators, applications providers, and/or service providers
• Each of these arrangements will normally be governed by an Architecture Contract that defines the deliverables, quality, and fitness-for-purpose of the developed architecture, and the processes by which the partners in the architecture development will work together.

• At the beginning of Phase G (Implementation Governance), between the architecture function and the function responsible for implementing the Enterprise Architecture defined in the preceding ADM phases; typically, this will be either the in-house systems development function, or a major contractor to whom the work is outsourced

  • What is being "implemented" in Phase G of the ADM is the overall Enterprise Architecture
    This will typically include the technology infrastructure (from Phase D), and also those enterprise applications and data management capabilities that have been defined in the Application Architecture and Data Architecture (from Phase C), either because they are enterprise-wide in scope, or because they are strategic in business terms, and therefore of enterprise-wide importance and visibility. However, it will typically not include non-strategic business applications, which business units will subsequently deploy on top of the technology infrastructure that is implemented as part of the Enterprise Architecture.

  • In larger-scale implementations, there may well be one Architecture Contract per implementation team in a program of implementation projects

  • When the finalised Architecture Definition Document is available (at the end of Phase F), an Architecture Contract will normally be drawn up between the architecting function (or the IT governance function, subsuming the architecting function) and the business users who will subsequently be building and deploying application systems in the architected environment

It is important to bear in mind in all these cases that the ultimate goal is not just an Enterprise Architecture, but a dynamic Enterprise Architecture; i.e., one that allows for flexible evolution in response to changing technology and business drivers, without unnecessary constraints. The Architecture Contract is crucial to enabling a dynamic Enterprise Architecture and is key to governing the implementation.

Architecture Compliance

Ensuring the compliance of individual projects with the Enterprise Architecture is an essential aspect of Architecture Governance. To this end, the IT governance function within an enterprise will normally define two complementary processes:

• The Architecture function will be required to prepare a series of Project Architectures; i.e., project-specific views of the Enterprise Architecture that illustrate how the Enterprise Architecture impacts on the major projects within the organisation (see ADM Phases A to F)
• The Enterprise and IT Governance functions will define a formal Architecture Compliance review process for reviewing the compliance of all projects to the Enterprise Architecture

Apart from defining formal processes, the Architecture Governance function may also stipulate that the architecture function should extend beyond the role of architecture definition and standards selection, and participate also in the technology selection process, and even in the commercial relationships involved in external service provision and product purchases. This may help to minimise the opportunity for misinterpretation of the Enterprise Architecture, and maximise the value of centralised commercial negotiation.